The following discussion of the background art is intended to facilitate an understanding of the present invention only. The discussion is not an acknowledgement or admission that any of the material referred to is or was part of the common general knowledge as at the priority date of the application.
Transaction servers are computer systems that manage operations of transaction processing. Transaction processing divides work into individual and separate operations known as transactions. An example of a transaction server is the IBM Customer Information Control System (CICS).
Transaction servers such as CICS are critical for the global economy because they process a relatively large number of transactions per day. Thus, it is important to guarantee smooth operation of the transaction servers. To guarantee smooth operation of the transaction server it is essential to monitor the transaction processing. Monitoring the transaction processing include (1) measuring the overall transaction performance and (2) gaining an understanding of what a particular application was doing while being processed in order to verify the accuracy and timeliness of programs and the corresponding application calls.
The monitoring process will permit during the lifecycle of an application to measure performance, diagnose problems and validate any changes made to the application. This is particular advantageous because it allows application developers to (1) measure the overall performance of the transactions during development thereof; (2) visualize the application events in detail e.g. EXEC CICS, DB2, IMS, MQ and Java calls, as well as program calls and returns; and (3) identify delays in transaction processing during testing prior to implementation into production.
Monitoring of the transaction processing is undertaken by, for example, visualising how transactions are executed in the transaction server (such as CICS).
CICS keeps a record of the processing of a computer program or the transaction. This record is called the CICS internal trace. The information collected from the internal trace can be used to assess problems and performance of the transaction processing.
The CICS internal trace is a virtual storage memory table that keeps a record of trace entries generated when either (1) CICS or an application program performs a function generating an application and/or system event or (2) CICS detects an exception condition.
In particular, the CICS internal trace is a series of linked buffers, each 4096 bytes (4K) in length. The buffers (also referred to as “internal trace buffer”) are adapted to receive the trace entries. The trace entries provide information about the particular application and/or system event or exception condition.
During operation, the CICS appends trace entries to the “active” internal trace buffer until it becomes full.
A disadvantage of the CICS internal trace is that when the table becomes full, the table wraps causing trace entries recorded in the past to be lost. Deletion of the trace entries occurs at regular intervals—in production the intervals may be only a few seconds. Thus, due to the internal trace table being located in memory and being transient in nature, the internal trace is typically inaccessible except in the event of a system or transaction abnormal termination when a dump is created.
Methods for overcoming the inability to directly access the information contained in the CICS internal trace table have been developed. These methods include (1) the formation of the CICS auxiliary trace, and (2) the installation of agents, hooks and exits to establish monitoring points (in lieu of the internal trace).
(1) The CICS auxiliary trace comprises a record of trace entries (also referred to herein as trace data). This record is stored in a data set called the auxiliary trace data set. The auxiliary trace data set is a sequentially organized data set on disk. While the auxiliary trace function is active, the trace entries generated during the transaction processing are stored in the auxiliary trace data set. There may be defined more than one auxiliary trace data set; this permits switching to other data sets when the data set that is currently being used is full. The data set is then post-processed in batch to format the trace entries for viewing by a user to and determine, for example, the reasons for an abnormal termination.
To collect large amounts of trace data it is necessary to initially define large enough auxiliary trace data sets; for example, if trace data is to be collected for a relative long period of time then relatively large auxiliary trace data sets will need to be defined.
The process for generating the auxiliary trace data set includes the step of activating the auxiliary trace option by the operator. Once a buffer containing internal trace data becomes full, the internal trace buffer is written to the auxiliary trace data set.
The disadvantage of using the auxiliary trace is that the writing internal trace buffers to the auxiliary trace data set has an adverse effect on the performance of the transaction processing due to adding to the overhead of the transaction processing conducted by the CICS.
(2) The second method for overcoming the inability to access the CICS internal trace table comprises of the use of monitors that record the application events of transactions as the transactions are being processed by the CICS. The recorded application events of transactions may then be viewed from the monitor user interface. An example of such a monitor is the IBM Tivoli OMEGAMON XE for CICS on z/OS.
The disadvantage of these monitors is that they use agents, hooks and exits inside of the CICS environment to intercept application events. The agents, hooks and exits are included to collect the level of detail required to diagnose application problems. The length of the code path for application calls made during transaction processing may be substantially increased; increasing transaction CPU and response times by including the agents, hooks and exits. The additional code is run by the CICS during the transaction processing; in particular CICS executes the agents, hooks and exits on behalf of the monitor; thus adding to the overhead of the transaction processing conducted by CICS.
Further, the inclusion of the agents, hooks and exits into the CICS environment requires CICS administration and changes to CICS to alter CICS operations.
Furthermore, CICS applications can run across multiple CICS regions; this is referred to as Multi-region operation (MRO). MRO provides transaction routing, function shipping and distributed program link (DPL) services that allow different parts of a single transaction to be processed in multiple CICS regions. Conventional monitors typically treat each CICS region separately, thus requiring each piece of a MRO transaction to be analyzed separately.
In summary, the conventional methods for overcoming the deficiencies of the CICS internal trace will be using resources of CICS thus adding to the overhead of the transaction processing conducted by the CICS. Moreover, as mentioned before, the internal trace is typically accessible only in the event of an abnormal termination and the resultant dump.
It is against this background that the present invention has been developed.